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“Without requirements and design, 
programming is the art of adding 
bugs to an empty text file.” 
— Louis Srygley © 2020 Philip Koopman 
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Coding Is Essentially 0% of Creating Software Mellen 





University 
What percentage of your design time is spent on 
each of the following stages? 


Developing overall system specs 





11% 
11% 


Conceptual design stage 12% 








Detailed design stage 


Simulation stage 





Testing and debugging 23% 


24% 


Prototyping | 12% © 2013 (N = 1,928) 






5% 
6% 8 2012 (N = 1,535) 


Sending to production & 





1 2011 (N = 1,679) 


Documentation/coding/mtgs 


(S designwe 


cntary Convention Center http://e.ubmelectronics.com/2013EmbeddedStudy/index.html 
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Old-School Waterfall Development Cycle _ tiller: 


Mellon 
University 
«ue m Effective for well understood domains 
Requirements 


e Works best if you don't make many big 
mistakes 
Software 


Requirements 






















— Variations on existing systems 


— Expensive to fix things that escape to 
High Level test steps 
Design 


e Any problem encountered requires 
backtracking 


— Note: original waterfall paper had these 
Soiree backward arrows! It was never just a 
Code unidirectional process 
Bugs 


Production 
System 
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What We've Learned in 50+ Years of Software Uhr 


= Dividing up into subsystems is critical US8If the second 





e Bad architecture will doom a project half of the 
= Process formality isa goodinvestment project is 
e Traceability, formal reviews, etc. “debugging” 





e Skipping steps costs more in the end that must 
= Requirements change mean the first 





e Suggests using an iterated approach half ts 
er 7a “bugging” 
= Finding bugs early is important eg wet 7 
e Traceability from high to low levels Ai pied MICA td 
‘ Layered testing testing.htm (paraphrase) 


e Peer reviews most cost effective for this © 2020 Philip Koopman 4 
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Finding Bugs Before Product Test Mello 
S Design = Product Testing 
we Peer Review 
\“o Code e Late & Expensive 











Peer Review 


Software 
Testing 


Product 


FIRST Testing 
50%-75% 
BUGS FOUND 
LAST 
5%-10% 
BUGS 
“SWISS CHEESE” FOUND 
MODEL 


SOFTWARE 
FAILURES 


e Many field escapes 
= Software Testing 
e Unit & Integration test 
= Code Peer Review 
e Earlier & Cheaper 
= Design Peer Review 
e Earlier & Cheaper 
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_V (or “Vee") Development Cycle See 


SPECIFY TRACEABILITY & VALIDATION ACCEPTANCE 





PROPER UCOOORORERROLOLOOROCOEOCCOROCUCOCOCOCOCCOCOROCCCOCCCCCCOCCT ST — Product 
PRODUCT Test Plan & Test Results 
- Product ¥4 Oe 
Requirements >. | Software Test Results 










SPECIFY 
SOFTWARE 


Saha ein Be eas wits SO Ee See Dees adn SOFTWARE 
Test Plan & Test Results TEST 





ftware Requirements < | | ' i ! Integration Test Results 


INTEGRATION 
TEST 


CREATE SW 
ARCHITECTURE 


Test Plan & 





=m Emphasizes 




















Test Results a traceability 
| Unit Test Results 
e Supports 
DESIGN L@ UNIT subsystem 
MODULES TEST decomposition 
Source Code @ Peer Reviews of 


aa work products 
IMPLEMENT :. 
| | © 2020 Philip Koopman 6 





Carnegie 


A Design Is Not The Code eee: 


University 


= Implementation: the code itself 
e Comments describe the implementation; they aren't the design 


= Detailed Design (DD) 
e Flowcharts 
e Statecharts 
e Algorithms, control diagrams, etc. 


https://pixabay.co 
m/en/flowchart- 
diagram-drawing 
conce pt-311347/ 





= High Level Design (HLD): architecture, component defs. 
e Pieces of the system (e.g., classes, subsystems) 
e Functional allocation to the pieces 
e Interfaces between the systems 
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Requirements on Top Leftof Vee Elim 


University 
= Software Requirements Specification (SRS) 
e Says ‘what’ the software does, not “how’ it does it 
— If it's not in the SRS, the software shouldn't do it 
— Avoids details unless mandatory due to marketing reqts. 
e Often paired with a Hardware Requirements Spec. 


= Product Requirements Specification (PRS) 
e Market-facing product requirements 
— What the system does from a user point of view 


e Point of interface between software group and others 
— Might just be a feature list 


— Might be in form of customer-specified acceptance test ©2020 Philip Koopman 8 








If you think 
good design is 
expensive, you 
should look at the 
cost of 
bad design! 














https://youtu.be/j-zczJXSxnw 
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Verification & Validation on Right Side of Vee — Mellen, 


m Unit Test: Traces to DD 

e Test individual subroutines, procedures, “modules” 
= Integration Test: Traces to HLD 

e Test module interactions (e.g., sequence diagrams) 
m= Software Test: Traces to SRS 

e Test functionality knowing how software is built 
= Acceptance Test: Traces to PRS Te eee Ter eee 

e Test customer-facing functionality Se ee ey 
m Other activities: 

e Software Quality Assurance (SQA): did you follow the steps? 

e Peer Reviews: check quality of every step 

e Regression Test: test after bug fix to make sure bugs stay dead 





oe 
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How Much ‘Paper Is Enough? 
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University 


= Old military development saying: 
e Deploy when the paper is heavier than 
the system. (Even aircraft carriers!) 


= Does all this mean you need to be 
buried in paper? No. 
e Paper required to check process health 
— Be clever about minimizing paper bulk 
— But if code has no paperwork, throw the code out 
e Put things on paper as you go through the Vee 
Documentation’ after writing code is really inefficient 
If you arent going to maintain paper, throw it out 
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Review: How Do the Pieces Fit Together? Calvenity 
ACCEPTANCE Product 







TRACEABILITY & VALIDATION 


TEST 






SPECIFY 
PRODUCT 





Software Test Results 








Product 
Requirements 


SOFTWARE 
TEST 





SPECIFY 
SOFTWARE 







Integration Test Results 


Software Requirements 


Pa diaae ene = Zales INTEGRATION 
TEST 


CREATE SW 














KR ARCHITECTURE a ws 
A Test Results 
eg High Level Design Unit Test Results 
% 
4 DESIGN UNIT 
% i MODULES TEST 
% Detailed Design Source Code 


S 
y IMPLEMENT 
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Principles behind the Agile Manifesto 


We follow these principles: 


Our highest priority is to satisfy the customer 
through early and continuous delivery 
of valuable software. 


Welcome changing requirements, even late in 
development. Agile processes harness change for 
the customer's competitive advantage. 


Deliver working software frequently, from a 
couple of weeks to a couple of months, with a 
preference to the shorter timescale. 


Business people and developers must work 
together daily throughout the project. 


Build projects around motivated individuals. 
Give them the environment and support they need, 
and trust them to get the job done. 


The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation. 


Working software is the primary measure of progress. 


Agile processes promote sustainable development. 
The sponsors, developers, and users should be able 
to maintain a constant pace indefinitely. 


Continuous attention to technical excellence 
and good design enhances agility. 


Simplicity--the art of maximizing the amount 
of work not done--is essential. 


The best architectures, requirements, and designs 
emerge from self-organizing teams. 


At regular intervals, the team reflects on how 
to become more effective, then tunes and adjusts 
its behavior accordingly. 


Carnegie 
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Agile Methods 





m Agile generally values: 


Individuals and Interactions over processes and tools 
Working Software over comprehensive documentation 
Customer Collaboration over contract negotiation 
Responding to Change over following a plan 


= Example: Scrum 


Daily “stand up” (“scrum”) meetings for face-to-face 

collaboration 

2-4 week long sprints to incrementally add functionality 

— Each sprint implements items from a backlog 

- Demo at end of sprint; theoretically a shippable product 

User stories serve as requirements 

Scrum challenges 

- Geographically split teams with informal communication 

- External dependencies (e.g., other parts of system change) 

— No time for extensive testing, especially embedded PBA YALE Koopma n 13 


http://agilemanifesto.org/principles.html 


Introduction to Scrum 


A’7 minute training 


Please watch this video: 
https://youtu.be/9 TycLROTqQKA 


by Steve Stedman 


Scrum Process Example 
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m Heavy on implicit knowledge 
e Where are the: requirements, design, test plan, acceptance test 


Stakeholder liaison 


=~ 


Product Owner 


~9 


road 


L4 


Product 
Backlog 





a?) Product 
ava . Backlog : 
- Refinement Daily Scrum 


ore 


Development Team 


Team forecasts 
work needed 
to achieve 
4 Sprint Goal ra 








Potentially 
Releasable 


Sprint Sprint » Increment i 
Planning Backlog 2 - 2 ¥e 
Topic 1: forecast PBI's ~~ = ; a 
Topic 2: plan work (e.g. tasks) Sprint a Sprint = eH 
Review Retrospective 
https://goo.gl/CkrCzR 
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When Is Agile a Good Fit? eee 
Source: Boehm & Turner 2004, Balancing Agility and Discipline ==” 
w Agile: = Plan-Driven (waterfall; V) 
e Small teams; small products e Large teams; large products 
e “Everyday” software quality e Mission-critical products 
e Fast requirements change e Stable requirements 
e High-skill experts throughout e High skill primarily in design 
project phase 
— Including life-cycle — Major versions require expert 
maintenance design 
e Developers can handle being e Most developers are not 


empowered; usually senior empowered; usually junior 
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Significant benefit is that it makes (good) developers happier ge &. 
e If done well can help with evolving requirements 

e But, but you need to manage and moderate the risks 

Issue: “Agile” is not just cowboy coding 

e Undefined, undisciplined processes are bad news 

e Yes, Agile teams should follow a rigorously defined process 

Issue: “No-paper” Agile unsuitable for long-lived systems 

e Implicit knowledge is efficient, but evaporates with the team 

e 10+ year old undocumented legacy systems are a nightmare 

Issue: Agile assumes 100% automated acceptance test 

e 100% automated system test is often impractical for physical interfaces 
e Often implicitly assumes that defect escapes are low cost because a new version is 2-4 weeks away 
Issue: Agile typically doesn’t have independent process monitoring (SQA) 

e Software Quality Assurance (SQA) tells you if your process is working 


e Agile teams may be dysfunctional and have no idea this is happening 
— Or they may be fine — but who knows if they are really healthy or not? © 2020 Philip Koopman 17 
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Best Practices For Software Process 
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: A - 
= Follow a defined process — = 
e Must include all aspects shown on Vee : 


— And SQA, Peer Reviews un 
e Its OK to rename and reorganize steps 
— All the steps have to get done 
— Common to see “AgileFall” etc. 
— Also common to see bad process 
dressed up with the latest buzzwords 
= Software Process Pitfalls 





e Skipping steps to get to testing faster means more bugs in test 
— Finding bugs is more expensive in testing 


e Using the wrong process for the wrong purpose 


— 3-Week product life and 30 year product life are different situations 
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HOW TO WRITE GOOD CODE: 


Do \. 
4“ THINGS ~ 
RIGHT OR DO 


ALMOST, BUT ITS 
BECOME A MASS 
OF KLUDGES AND 
SPAGHETTI] CODE. 





https://xkcd.com/844/ 


